kernel exploit

MoMo 6o Wrote:

OOKAMI Wrote:bon

ca a bougé coté hotz

j'ai pas encore tout lu mais le titre est super interessant puisqu'il semblerait qu'il ai acces aux SPE isolés !

affaire a suivre !

Tu a été prévenue GeoHot, on avait dit "pas un mot sur le net sinon..."


Ok je sors =>

A Level Playing Field
Right now, I'm playing with the isolated SPEs, trying to get metldr to load from OtherOS. Interesting thing, I am not using the exploit. I always assumed the enable isolation mode register was hypervisor privileged. It's not, it's kernel privileged, which means using hypervisor calls you can all get to it. So, get to hacking. Here is the code I am playing with.

I'm not that opposed to releasing the exploit, but I think the majority of you are going to be disappointed, even if you do get it working. Unless you have pushed the HV to it's limits, this exploit really isn't going to do much for you...yet. So install OtherOS and start playing around. If people start coming up with convincing reasons why they need the exploit to go further, I'll release it. It's just a waste to release if people can't make use of it.

As far as the GPU goes, I have full access to the GPU memory space 0x2800... But without a driver, it's useless. 3D video card drivers are notoriously hard to write, look at the ATI and NVIDIA ones for linux. The best are still the closed source manufacturer ones. I'm not even sure I believe that the HV restricts video card access, just that the OtherOS driver is 2D. If someone skilled in video card driver development comes forward, and they can explain in detail what the HV is restricting, I'll send them the exploit.

And something has to be done about the comments. Theres a couple of good ones, mixed in with tons of trash. Please, if you don't have something technical and useful to say, don't say it. This is not the place for congratulations(go back to the hello hypervisor post), debates about piracy(go somewhere else, the internet is big), or trying to convince me to do X.

De plus, il faut savoir que depuis le 6.00, Sony a modifié structurellement le firmware et a retiré un certain nombre de choses "inutiles" pour faire tourner les jeux mais indispensables pour lancer certains utilitaires et autres homebrews. Ceci a été pallié, en grande partie, par nos fendus du développement mais il faudrait obliger une mise à jour générale de tous ce qui existe en homebrew (jeux et utilitaires) ainsi que les thèmes et tout ce qui va avec. En effet, nous sommes arrivés avec le 6.xx à un point qui rappelle le passage des homebrews 1.xx à celui des 3.xx mais en pire. En effet, le 6.xx ne permet plus le lancement des ELF en l'état et il faut repack tous les programmes afin de les rendre compatibles avec le nouveau système de Sony[...].

Voila un message de MathieuLH sur la partie forum d'un site concurent, pour info, Mathieulh etait quelqu'un de tres présent sur la Scène psp.Il s'est aussi interressé à la ps3. Enfin cest pas un idiot il sait de quoi il parle

Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.

Mathieulh Wrote:Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.

Mathieulh Wrote:Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.

Mathieulh Wrote:
Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour le jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.

lululombard Wrote:

sephirothff Wrote:apres avoir visionner la vidéo de plus pres et fait quelques recherches , la méthode utilisée est identique a celle que l'on utilisait pour jouer a des jeux de firmware suppérieur aux débuts de la PS3 , a l'époque on pouvait avec quelques jeux comme motorstorm faire un swap pour lancer des jeux demandant un firmware plus élevé , donc j'emet des doutes sur l'utilité de la sauvegarde . reste a voir si ca marche avec des backups récents ce dont je doute

la ou j'aimerais avoir des infos c'est au niveau de la modification de la sauvegarde , il n'est fait mention nulle part d'une méthode . quels sont les offsets modifié ?

Je savais même pas que MotorStorm servait dans le passé.
La sauvegarde a été modifié juste pour que le SuperVisor n'est rien d'autre à foutre que vérifier la sauvegarde en boucle.

fiftybo Wrote:J'suis totalement contre un lanceur de "Backup" . J'vois pas l'utilité, tout les gens vont télécharger leurs jeux sur internet, comme avec la PSP, la DS, la WII si un est crée.

Un lanceur d'Homebrew oui ce serait génial, mais un luncher d'ISO, ça signifie piratage de jeux a fond ! Surtout avec les débits actuels de 1MO/s, et la fibre optique n'en parlons pas ! Pour les jeux de 25GO ça reviendrais à 7h de téléchargement. J'suis totalement contre.

Je m'occupe pas de ce que les gens vont faire avec ce programme, Hadopi est là (bien que je suis contre) et moi même je trouve 70€ abusé pour un jeu.
En plus, avec ma méthode on peut lancer des HomeBrew gravés sur Blu-Ray si tout se passe bien

dann448 Wrote:ça sent fort le fake

mais bon pourquoi pas esperer en attendant la revelation. de toute façon tout le monde sait que le kernel 6.xx est modifié et ferait d'énorme incompatibilité avec les utilitaires/plugins ou homebrew des précédents kernel qui devront être mis à jour